-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find/Replace overlay: fix Ctrl+F6 crash on Linux #1975
Find/Replace overlay: fix Ctrl+F6 crash on Linux #1975
Conversation
@iloveeclipse can you please confirm that this fixes your issue on Linux? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR fixes the problem on Linux, thanks. Some smaller issues see in comments above.
} | ||
|
||
getShell().setVisible(isPartCurrentlyDisplayedInPartSash()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code called from asyncExec()
without checking whether preconditions are still met : the targetPart
is still opened and it's shell is non null.
Same for the code below in the asyncExec()
call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add checks for whether the shell is still open, sure. How do I check whether the targetPart is still open? I didn't find a method for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targetPart.getSite().getPart() would be null.
...es/org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/texteditor/FindReplaceOverlay.java
Outdated
Show resolved
Hide resolved
Test Results 1 210 files ±0 1 210 suites ±0 1h 3m 33s ⏱️ + 3m 14s For more details on these failures, see this check. Results for commit 4289711. ± Comparison against base commit d67d6c7. ♻️ This comment has been updated with latest results. |
b85fd61
to
a5a9122
Compare
I am not sure if my PR is failing but it looks like it isn't? |
} | ||
|
||
@Override | ||
public void partDeactivated(IWorkbenchPart part) { | ||
// Do nothing | ||
Display.getDefault().asyncExec(this::adaptToPartActivationChange); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better to use getShell().getDisplay().asyncExec
- here and below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: getShell() is not the "Eclipse Shell" but rather the shell of the Dialog.
Since this asynchronous execution is very quick, it's likely not a problem (?)
@@ -262,6 +258,32 @@ public void partClosed(IWorkbenchPart part) { | |||
public void partOpened(IWorkbenchPart part) { | |||
// Do nothing | |||
} | |||
|
|||
private void adaptToPartActivationChange() { | |||
if (getShell() == null || targetPart.getSite().getShell() == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targetPart.getSite().getShell() == null
that is same as getShell()
. Instead, check for the targetPart.getSite().getPart() == null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that is not the same as getShell()
as this code is ran from inside of a Dialog. getShell()
returns the shell of the Dialog, and targetPart.getSite().getShell()
returns the the shell which contains the part we are targetting.
Sure, I can change the check for whether the part is null. Please refer to my comment down-below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pleas ehcekc whether my change in ad63e43 is addressing your concerns
...es/org.eclipse.ui.workbench.texteditor/src/org/eclipse/ui/texteditor/FindReplaceOverlay.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
private void focusTargetWidget() { | ||
if (targetPart.getSite().getShell() == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targetPart.getSite().getShell() == null
should be replaced with getShell() == null || targetPart.getSite().getPart() == null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't quite understand why that makes sense, but if it is true that targetPart.getSite().getPart() != null
implies targetPart.getSite().getShell() != null
, then that should work by contraposition.
Please keep in mind that this code is ran from inside a Dialog, so getShell()
does not return the same shell as the shell the part is located in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I performed the changes in ad63e43
LGTM now :-) Once Andrey's remarks have been addressed, this PR can be merged- |
1f97f91
to
ad63e43
Compare
@iloveeclipse have your concerns been addressed (in particular #1975 (comment)), so that we may merge this PR? |
I haven't checked the PR since, but please rebase before merge, so we see test results with latest master state. |
ad63e43
to
09865c8
Compare
Sure, I have just rebased it to get some recent test results but depending on when this PR will be marked as ready to be merged, we will rebase again. |
09865c8
to
126ba0d
Compare
@HeikoKlare @akurtakov I have merged this PR with the latest master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@Wittmaxi : thanks, I've finally had time to test the patch, it fixes the problem. Please manually rebase on master, as due the package move the change can't be merged. |
@HeikoKlare I won't get to merge these changes until next monday. If you have some spare time and if it's straight-forward to do, could you please merge them to master? |
126ba0d
to
23d62ec
Compare
I've rebased the changes on master. The local Git client is able to automatically consider the file relocation when performing a rebase, so rebase was performed without manual effort and thus without the risk of unintended changes/mistakes. Once the GitHub checks have finished successfully, we can merge this. Edit: I had to apply a slight change concerning the way the source viewer is accessed (https://github.com/eclipse-platform/eclipse.platform.ui/compare/23d62ec2c50dc399b7049afdebe22922b7dcf70d..6e143ebff2b1705d52e9f4e1984e7faadcf71175), exactly like applied at other places when moving the find/replace classes in a separate package (#2013). |
23d62ec
to
6e143eb
Compare
Avoid being stuck in an event loop by reacting asynchronously to part activation events. Additionally, manually give focus to the editor part after switching. This behavior is default on windows but not consistent on Linux. fixes eclipse-platform#1951
6e143eb
to
4289711
Compare
I've tested the change on Linux, Windows and MacOS. I can also confirm that it fixes the reported bug on Linux and also works as expected on Windows and MacOS. |
Avoid being stuck in an event loop by reacting asynchronously to part activation events.
Additionally, manually give focus to the editor part after switching. This behavior is default on windows but not consistent on Linux.
how to test
after pressing Ctrl+F in a few different Editors,
(on Ubuntu), press Ctrl+6 repeatedly to switch between Editor parts. We (quite obviously) don't expect anything to crash!
fixes #1951